How We Engineer Enterprise Systems

Systems Engineering (SE) tools and methods developed and used in consulting and IT systems integration business are presented in the paper. Effectively managing the uncertainty and unknowns, clearly translating customers’ needs into requirements and further verifying and validating them, as well as the preliminary estimation and the strong control of the full scope of project work (timeline, resources and quality) are identified as the key consulting capabilities. The paper describes the methods developed and proved by practical usage to strengthen such capabilities and to engineer enterprise systems. Systems Engineering in Consulting Project Domain The business focus of IBS company (www.en.ibs.ru) is now on the professional services in management consulting, HR consulting, IT system integration, IT applications implementing and other various consulting areas. IBS was established in 1992 and until 2000 the company focused on IT infrastructure projects, computers and networking equipment delivery. In 2002 the business was dramatically transformed into the professional services area [1]. Since 2010 IBS has been annually nominated as the #1 consulting company in Russia according to national ratings. Over 80% of the largest Russian companies of various industries including government, energy, oil & gas, machinery, retail and banking are clients of IBS. The company helps these businesses to develop all facets of business governing systems, to improve business processes, to implement IT applications, to engineer infrastructure, etc. All these activities are part of SE domain and IBS delivered thousands of such projects during their years of operation. The key success factors of any firm or business are the capabilities to develop new products/services; to meet customers’ expectations; to deliver on time, with high quality and at competitive prices. In case of consulting business these statements mean that “all” (the more the better) consulting project activities should be executed according to corporate standards and rules which guarantee predictable and controlled financial results. After the long operational background practically all companies have mastered in full the capability to execute standardized project tasks effectively. But the following project delivery capabilities are absolutely critical: • To operate effectively in uncertain and unknown environment (to develop new technologies/products/services); • To translate customers’ needs into requirements, to verify and to validate them; Copyright © held by the authors. INCOSE Italian Chapter Conference on Systems Engineering (CIISE2014) Rome, Italy, November 24 – 25, 2014 • To estimate preliminary, at presale stage, the full scope of project work (timeline and quality, project resources spending) and to control it during delivery. Figure 1 represents the consulting projects domain. The diagram is developed based on the figure from [2], page 504 (“lower blue” part of the diagram). “Blue” entities represent the elements of an enterprise system; “upper green” entities were appended to represent elements of the project itself. Figure 1. Consulting Project Domain The “Governing Body” of any consulting project aim is to deliver some “Value” to “Stakeholders”; orange arrows at the diagram show this multitier and indirect governing-body-to-stakeholder-value link (GBSV-link) which is essential for successful project execution and for consulting business as a whole. SE tools and approaches were developed to control different tiers of the GBSV-link, to improve project delivery capabilities, to standardize processes as much as possible and to facilitate project delivery. All tools were initially developed during practical delivery of the real projects to customers and later they were generalized, described and formed as the tools. The tools and approaches do not substitute for any project management or systems engineering processes, nor for any standards or guidance, rather they supplement them. The paper presents the following approaches and tools: Integrated Product and Project Viewpoint & Sort-by-Readiness-Level-Rule; Agile Project Management Guidance; Capabilities Chain Framework; Capital Project Architecture Framework. Integrated Product and Project Viewpoint & Sort-byReadiness-Level-Rule The viewpoint and the rule were developed to manage the uncertainty and unknowns by specifying, localizing and narrowing them. INCOSE Italian Chapter Conference on Systems Engineering (CIISE2014) Rome, Italy, November 24 – 25, 2014 Some projects challenge IBS with the considerable uncertainties and unknowns which make standard project management, disciplinary engineering and systems engineering approaches practically useless. For example, it happens when new unknown technology must be used. The deliverables and, as a consequence, the financial outcome of these projects might not be secured and special guidance was developed to govern these cases. A project is a “temporary group activity designed to produce a unique product, service or result” [3]. In cases of complex technological projects main risks might not be analyzed and controlled based only on “activities”; the most crucial risks emerge from uncertainties and unknowns of technology and design of the system of interest (SoI), the product. So an integrated viewpoint (figure 2) should cover both areas, activities and SoI, to be useful. Figure 2. Integrated Product and Project Viewpoint The left-hand portion of Figure 2 represents the traditional project management area – which is activities based: work, resources, teams, etc. The right-hand portion of Figure 2 depicts SoI and external environment, which cause the uncertainties mentioned above. The system of interest is represented by the system’s architecture and the components (or constituents) which might also be complex entities or systems. The risks derive from uncertainties and unknowns of technology and design as well as from the external environment are influenced by the following threads: 1. Direct influence on the SoI; 2. Influence on the efficiency of the SoI operating in the environment; 3. Changes in the environment cause changes of the requirement to the SoI. The Integrated Viewpoint (Figure 2) is very appropriate to be used as the template to model the SoI and project activities in integration. Such models can be developed at INCOSE Italian Chapter Conference on Systems Engineering (CIISE2014) Rome, Italy, November 24 – 25, 2014 any level of detail and might be used to visualize the risks; to localize and manage them; to communicate inside the project team; to monitor project progress; to study the effectiveness of the project team; and to control the architecture and product itself; etc. The model of the project and SoI should be drawn as a diagram similar to Figure 2 with attributes and text description. The Sort-by-Readiness-Level-Rule employs ideas that for the most part, all elements of the design of SoI and technologies stay at unequal readiness or commercialization levels. In turn, different levels cause different uncertainties and different risks which should be controlled differently. The following table summarizes the rule three readiness/commercialization levels are used to sort all elements of the technologies and the design of the SoI (left column), and appropriate approach is used to control the technological risks derive from element (right column). Table 1: Sort-by-Readiness-Level-Rule summary Readiness/Commercialization Level Approach to manage the risk Well known, practically proved solution, like COTS / GOTS Monitor supplier, subcontractor Known solution with minor modifications Monitor modification process. Completely new solution Use number of alternative solutions. Use scenarios approach. Monitor design process. To be applied the rule requires making a list of the technology/design elements then sorting each element into one of three groups and using an adequate approach to manage the risk. The list is usually in table form with each line having one element; and the following columns: • The name and the summary of the element, • Readiness/commercialization level, • Description of the activity to manage the technological risk associated with the element. Such a list is a very suitable tool to visualize technological risks, and to put them in some order for managing them. Agile Project Management Guidance In early 2000 IBS management conducted a drastic transformation of the strategy and business model of the Company [1] and Agile Project Management approach was used for the first time. At that time IBS was one of the key players in the Russian IT systems integration and IT infrastructure projects field (complex computing systems, multiservice networks, etc.), with approximately 950 employees and annual revenues of around $80M. In 2001 the top management of IBS detected considerable economic changes and predicted a dramatic growth of IT services and the consulting market in Russia based on these factors. This forecast turned out to be correct; Russian IT services and consulting market grew five-fold from 2001 to 2010. INCOSE Italian Chapter Conference on Systems Engineering (CIISE2014) Rome, Italy, November 24 – 25, 2014 Based on the forecast described, IBS management created a new company strategy aimed at the switch to IT services and consulting businesses, namely, the share of IT services and consulting needed to be increased from 25% to 50% or more over one year. It was evident that such dramatic changes of corporate capabilities and the firm as the whole might not be done in an evolutionary fashion. Thus, a fundamental transformation was necessary, and such a transformation was executed in 2002. From a SE point of view, IBS firm (consisting of autonomous business units) exemplifies a system of systems (SoS) and enterprise system (ES). All SoS aspects (complexity, emergency, soft-governing-instead-of-directive-control, networkrather-than-hierarchy, self-organization, adaptability, etc.) are natural and typical for the “extended enterprise around IBS”. All stages of the transformation (concept development, planning and implementation) constitute a set of exemplary SoS as well as ES engineering activities. The transformation was, in reality, a rather compact program of projects which fully configures the model in Figure 1. The project teams consisted of the company’s employees and the program of projects were governed by the corporate governing center (CGC) according to a single program plan. The transformation task did not look complicated from a project or program management point of view. Organizational change implementation was a standard activity with a well-known personnel resistance problem and proven approaches to overcome this resistance. Deep involvement of top management, headed by the CEO, guaranteed effective project management and execution as well as organizational management implementation. All transformation activities were conducted in parallel to save time and resources. Joint workgroups of employees were formed at levels below the officers, and CGC integrated the workgroups at the management level. In effect, a multi-level integrated workgroup was formed. The major complexities and/or problems derived from the unknowns / uncertainties: • The risk of mistaken forecast of economics and IT-market development; • A very high complexity IBS as ES/SoS; • The lack of experience in such transformation; • The shortage of professionals in consulting area at that time. These uncertainties could not be controlled by means of additional research and study: the transformation team did not have the required time. Experiments and tests also would not help: there was no testing or training area to check solutions before implementation and all solutions were piloted within a working company and going business. The quick and effective creation of solutions and their practical testing is a very natural and rational approach to manage such uncertainties. The main idea was to accelerate the circle or loop “define requirement–design-implement-validate”, when there is no other way. Initial conditions and the approach mentioned led to many changes in the implementation process, thus it was necessary to manage them fast and effectively. Based upon the understanding of insufficiency of traditional activity-based project management, the management team formed a “project kernel” including the specification of the Integrated Product and Project Viewpoint (figure 2). INCOSE Italian Chapter Conference on Systems Engineering (CIISE2014) Rome, Italy, November 24 – 25, 2014 Such a project kernel covers the key part of the complex project domain and enables the governing of uncertainties. Both parts of the kernel were used as an aggregate, not only the plan but also the architecture description was used to monitor the progress and to make changes, etc. The following principles were used to manage the portfolio of projects in the event of a lack of experience and ready-to-use algorithms and methods: • Form solutions as fast as possible (without regard to pure quality) and quickly test it in practice; • Failures are unavoidable, perceive them easily and react rationally; • In case of failure analyze the situation, find a new solution, generate changes, then update the plan – rebuild project kernel; • Work in parallel, verifying and coordinating intermediate results; • The schedule and architecture may be corrected and updated but should not be violated due to improper execution – follow project kernel; • Formulate and test the most critical and questionable solutions first; • Start with pilots and then, if they seem to be working, roll them out to cover the whole scope; • Use high level and highly qualified management to control piloting a developed solution to avoid a waste of the resources. Following these principles, implementing a strong sense of discipline, a high level of sponsorship, and the involvement of all employees enabled the transformation to be completed in time and without hiring consultants while maintaining and developing on-going business. Later Agile Project Management Guidance (APMG) was formed as the set of: • The instructions on how to form and use project kernel IPPV diagram; • The set of principles listed above and instructions on how to use them; • Use cases including models of exemplar project kernels in textual form or as IPPV diagram (figure 2); descriptions of the examples of failure analysis, rebuilding project kernel, working in parallel, verifying and coordinating intermediate results. APMG is a very appropriate model to manage complex projects in cases of high uncertainties, unknowns and the turbulence of external environment causing changes in the requirements for the systems. Capabilities Chain Framework The transformation of IBS, described above [1], was treated in reality as a creation of new capabilities of the enterprise system. To achieve this strategy goal, the company’s management defined new capabilities required to sell and execute big and complex multi-disciplinary consulting and services projects. Sales and execution processes should be treated as absolutely standardized, regular and routine procedures. “Capabilities” is used in terms of [4]: “A business capability is what the company needs to execute its business strategy. These capabilities are operational in nature. Another way to think about capabilities is as a collection/container of people, processes, and technologies that is addressable for a specific purpose.” A capabilities based approach was developed at that project; later the approach was generalized and Capabilities Chain Framework (CCF) was formed. INCOSE Italian Chapter Conference on Systems Engineering (CIISE2014) Rome, Italy, November 24 – 25, 2014 The transformation process was executed as the following sequence: 1. Analysis & Capabilities decomposition. In the initial analysis the IBS mission was translated to capabilities; and “understanding the constituent systems and their relationships” was executed. The transformation team found that capabilities might not be directly translated to any business-agent. Neither autonomous business units (they serve as resource pools), nor project teams (being temporal elements), nor employees (each of them has a very limited set of skills, experience, responsibilities, etc.) might realize necessary capabilities. 2. Key areas definition. Realizing this transformation the team defined several key areas of the company’s operations or activities which were supposed to be changed to form new capabilities. It was planned in each of the areas to engineer and to implement tools supporting new capabilities (operational rules, technologies, processes, tutorials, guidebooks, software systems). Five key areas of operations or activities were defined: • Core technologies area – consulting and services area; • Project implementation area; • Business unit growth area (hiring and newcomer integration); • Motivation of the employees area; • Management accounting area. For each of the areas an appropriate system to support new capabilities was developed and implemented. These new capabilities support systems formed exactly the corporate infrastructure of a new business model. 3. Concept development. For each key area a set of design documents was developed, describing approaches, policies, system; the documents formed the business architecture description of the company, although this term was not used at that moment. The architecture description links or connects all key areas together and defines the target operation model of the company after transformation. At this stage capabilities were translated into the requirements for the systems and for the interfaces between them. 4. Body of the new capabilities support systems development (for each key area). After architecting, the capabilities support systems were designed. 5. Pilot implementation (for each key area). The new capabilities support systems (procedures, guides, documents, software systems) were initially implemented in pilot zones to save time for the testing and “re-implementing” after changes. 6. Roll-out (for each key area). After piloting the new capabilities support systems were rolled out to the full “extended enterprise”. At stages 4-6 capabilities were used to verify and validate design solutions and the systems. 7. Operation & Assessing Performance. Assessment at operational stage 7 is a real check of company capabilities. Stages 1-7 realize a backward movement along GBSV-link (Figure 1) from desired capabilities to systems implementation. In the transformation project [1] the “mission-to-capabilities” decomposition included five major capability groups of focus: 1. Deliver consulting and services. 2. Sell complex consulting projects. INCOSE Italian Chapter Conference on Systems Engineering (CIISE2014) Rome, Italy, November 24 – 25, 2014 3. Execute and deliver complicated multi-discipline consulting projects. 4. Manage human resources effectively. 5. Measure and account projects, BUs’ and employees’ performance. Each group consists of the set of capabilities which, in turn, are transformed into systems requirements. For example, the 5 th group includes: measure and estimate work-in-progress, value earned, spent cost; do this “on-line”; plan and forecast financial result of the projects based on initial plans and progress measurements; plan and forecast corporate financial and other performance indicators based on the forecasting of financial results of the projects and other indicators measured “in progress”. The relation between SoI and stakeholder value (GBSV-link, Figure 1) is very complicated and indirect, but very important. The main purpose of the CCF is to simplify and to standardize the control of the link and ensure at any stage of the project that developing SoI will really deliver value to stakeholders. The framework is based upon simple practical rules summarized in Table 2. A “Requirements-tocapabilities” checklist is a very important practical tool to ensure the controllability of the GBSV-link. The checklist is usually made in the form of a structured bulletlist, visualizing the fact that each desired capability is supported by appropriate requirements for the systems. CCF also includes use cases with the descriptions of exemplar capabilities, exemplar “Requirements-to-capabilities” checklists and the descriptions illustrate the rule and facilitate CCF usage. For example, the list of 9 universal capabilities of IT-systems was developed in [5] and is included into CCF; such universal capabilities might be used as templates to formulate concrete capabilities at stage 2 in IT-systems implementation projects. Also a diagram similar to Figure 1 may be used to visualize GBSV-link in particular case, the diagram must be concretized to real concrete capabilities, systems components, etc and may be used to as a part of CCF to control GBSV-link. Table 2: Actions and deliverables of the CCF rule